Netware Super Library/Netware Super Library.iso/virus/vste204/vsuite.doc

Text File | 1995-03-21 | 29KB | 576 lines

VSUITE.DOC: Documentation for the Virus Script Suite version 2.04
File last updated Tuesday March 21, 1995.

        ╔═════════════════════════════════════════════════════╗
        ║Important: Read the LICENSE section of this document ║
        ║   for important info about updates and bug fixes!   ║
        ╚═════════════════════════════════════════════════════╝

CONTENTS

   I.     INTRODUCTION
  II.     REQUIREMENTS
 III.     FILE DESCRIPTIONS
  IV.     INSTALLATION
   V.     MORE INSTALLATION
  VI.     LOGIC OF OPERATION
 VII.     NOVELL RIGHTS REQUIREMENTS
VIII.     LICENSE
  IX.     AFTERNOTES


I. INTRODUCTION

This package was written as an alternative to buying expensive NLM
software for our Novell network here, in order to provide a safe and
reliable virus scanner for our lab and network users. I wanted to
provide a fast and easy interface which required little if any knowledge
of computers to use, to enable virus scanning of both floppy and hard
drives. I also wanted centralized reporting if anything was found, or if
problems occured during scans. I also wanted to make the system easily
editable, configurable, and repairable, which I believe I have managed
to do.

These are, essentially, just 4DOS scripts... but a LOT of lines of
script at that, and they do some pretty novel things, such as building
other scripts and configuring software, auto notifying, and more.

I thought about compiling the scripts, or even rewriting the scripts
into Pascal or C, but to be honest, I like to be able to change them so
frequently, and to make bugfixes when necessary, and I thought you might
want to be able to customize them, too. If you DO want to compile them,
see the 4DOS documentation for the BATCOMP command.

A caveat: I have tried to avoid the mindset that says when one is writing
documentation, one should approach it with the levity of an accused
prisoner of the Spanish Inquisition.  Forgive me this, if nothing else.

The documentation seems, to me, to be kind of thick... but I am pretty
specific about a lot of things in this document. Take what you need and
leave the rest, but I would recommend reading through it in its entirety
before you attempt to install, so you know what's going on. (I know, I
know... 500 lines of documentation? for some SCRIPTS?!?!)

I did a complete rewrite of the Virus Scanning for version 2.0. If you
were familiar with it before, you know about the fact that you needed
not ONLY to be using Novell 3.xx, 4DOS, and F-Prot, but you also needed
to be using Pegasus Mail for notification, plus you needed about five
little UNIX-like utils such as GREP, SED, HEAD, and more to be able to
use this package. The requirements have slimmed; see the REQUIREMENTS
section for more info. Speaking of which....

II. REQUIREMENTS

I have changed the format of this system, along with providing a more
user-friendly interface, so that the requirements to run the scripts
are now:

        Must be using Novell 2.xx/3.xx (I have not made any 3.xx calls, so
        it should actually work with any Novell version that includes the
        command WHOAMI; I unfamiliar with version 4.xx, but I would also
        assume it works fine under that release of Netware)

        Must have F-Prot installed on your network drive, publically
        accessible (but not necessarily on the public path)

        Must have 4DOS, in a publically accessible locatiion which is on
        the network path. (possibly where you install your vsuite
        files).

Hardware requirements are about 100K of free space on the server.

That's it! No mailer is needed, nor any utilities save 4DOS and F-Prot.


III. FILE DESCRIPTIONS

Here's the list of what this package comes with:

   HISTORY.TXT  --  A short version of what has changed through
                    all release versions.

   INSTALL.BAT  -- DOS script to check for 4DOS 5.0 and launch
                   INSTALL.BTM in a 4DOS shell if found.

   INSTALL.BTM  -- 4DOS script to take user information and build the
                   scanner scripts.

   MAKEFILE.1-6 -- Files used by the installer during the build process.

   VSUITE.DOC   -- This file. (aside from the obvious...)


Here's what you need to get from a SimTel mirror (such as
oak.oakland.edu, ftp.cdrom.com, or wuarchive.wustl.edu) if you don't
already have 'em:

        F-PROT          -- Virus scanner. It can be found in /msdos/virus,
                           with a filename of fp-xxx.zip, where xxx is the
                           current version number. At this writing,
                           2.16d was the current version, but as Frisk
                           is so wonderful about updates, there are
                           probably newer versions out there by the time
                           you read this.

        4DOS            -- The wonderful shareware shell. Pick it up in the
                           SimTel directory msdos/4dos, under the filenames
                           4DOSxxA.ZIP and 4DOSxxB.ZIP, where xx is the
                           current verison number (ergo, 4DOS55A.ZIP and
                           4DOS55B.ZIP at the time of this documentation).

        As these are shareware utilities of an excellent quality, and
        have a more than reasonable registration price, I will suggest
        registering them both.  If you use them, and you WILL once you
        try them, you should help support them.


IV. INSTALLATION:

You can install the scanner to a local drive to practice, or test it
out. Just give the Installer appropriate local directories instead of
network directories, and it will work. This version of the scanner was
written on a standalone machine, and bugfixed on a Novell 3.12 network.

If you have already installed a previous version of the scripts, never
fear. The system will clean out the old files before installing the new.
Just give the program the same directory where the previous version is
installed.

Unpack this archive. Wait.... you've already done that.

Make a directory, in a publically writable area, to store virus reports.
Note: virus reports will ONLY show up if viruses are reported, not with
every scan.

Make sure you're in the directory you unpacked the archive -to-, and
type INSTALL. Most of the installation is pretty simple, but here, is a
step by step description of what you need tell the installer when it
asks for information:

First of all you need to read and agree to the disclaimer. I cannot be
held liable for this script's performance, in part because the
installation procedure assumes that you know what you are doing in the
first place, and secondly, because I don't know what your network looks
like. If I did I'd have to be doing your job. :-)

Please understand that not only have I spent a few hundred hours or so
working on the various versions of these scripts, and not only have I
presented this information and these scripts to my own colleagues, but
that I use them myself, with some minor modifications. We will talk
about those in the MORE INSTALLATION section below. I am fairly certain
that they should work for anyone running Novell, but if bugs do occur,
please let me know. I'd like to have a stable utility out there.

After agreeing to the disclaimer, you'll be asked to give your scanner a
title. This can be anything you wish, and you'll be given a rough
example of what you enter as it would appear in the title of the
scanner, so that you can verify that what you see is what you want. The
title needs to 68 characters or less wide.

The next several screens will request information about how where you
want to put files and where the scanner can find files. When
appropriate, if you enter a path which does not exist, the script
will ask you if you wish to create that directory. In any case, trailing
slashes are removed from all paths, and you will be asked to verify each
entry for correctness. If you say "n" to any of these questions, you
will be prompted to re-enter the information.

╔══════════════════════════════════════════════════════════════════════╗
║ IMPORTANT TECH NOTE: I have found as of recent that 4DOS data piping ║
║ will NOT work properly with Novell directory namespacing.            ║
║ Whatever you do,  DON'T use Novell-style (SERVER/VOL:DIR\SUBDIR)     ║
║ pathnames for your network drives when queried by the installer. Use ║
║ the old F:\PUBLIC names.                                             ║
╚══════════════════════════════════════════════════════════════════════╝

First, you will be asked to enter a directory which the scripts can
store F-Prot on users' local drives. This was changed from previous
versions, where the users would load F-Prot from a network drive each
and every scan they did. I got rid of that, because the load increase
from just our lab machines was staggering. For more information on what
the scanner references, check the LOGIC OF OPERATION section below,
which gives a complete rundown. If this directory does not exist on a
particular machine, when the scanner is run on that machine it will
create the directory after checking to make sure enough space exists for
F-Prot.

The next path you will be asked to enter is the path to a network
directory where you'd like to store the latest version of F-Prot. This
is called the Archive Directory, and when you get a new version of
F-Prot all you need to do is unpack the COMPLETE archive for it into
this directory. When a user scans their workstation, a version
comparison is made between the version of F-Prot in the user's local
F-Prot directory and the version in this Archive Directory, and if the
version has changed since they last scanned, they will be notified to
wait while their local version is updated. The newer version will then
be copied to their drive, relieving you of the burden of updating
everyone's verison of F-Prot.

Up next, you're asked for a location to build the Virus Script Suite's
scripts. This MUST be a public directory on a network drive, and it MUST
be on the public path, otherwise your users won't be able to scan their
machines by just typing VSCAN. I've always used \PUBLIC\BATCH, which
around here we added to the system login file drive mappings; you may
prefer \PUBLIC, but I've found having half a gig of small files in one
directory slows access time. Don't forget: -Don't- use Novell-style
names!

Then, you will be prompted to enter the name of a directory which can be
found on each user's system, to create a temporary report file which
will be deleted automatically, unless viruses are found. I use C:\ for
our temporary directory here, since this file is deleted. You may prefer
to use another directory, but make certain it exists on all of your
workstations. If this directory does not exist on the users' machine, it
will be created for them.

Finally, you will be asked for the path to a report file directory.
This is a directory on which the scanner file SUMMARY.TXT is stored,
into which are added the "virus found" alerts, and which is checked by
a script which you will later add to your Novell LOGIN file. We'll
discuss the need for this file and directory in the LOGIC OF OPERATION
section, but for now, just enter the name of a network directory which
is publically accessible, but not necessarily on the public path. Here,
we use <server>\SYS:\PUBLIC\LOGINS\VREPORTS.

You will then be asked to verify that all of the information you have
entered is correct. If you wish to change anything, press "n", and you
will be able to re-enter all of the directory paths and the scanner
title again.

After this, the Installer will build its necessary files in the directory
you told the Installer to use for scripts.  Provided there are no
problems compiling the scripts together (which I have done on different
machines probably forty or so times during internal testing), you will
be done. Try running the scanner from a test account, if you have one,
or a lab machine. The program name the users will enter is VSCAN.

Note that the VCHECK program automatically creates a log file if it does
not find one. More on this script in a bit.

V. MORE INSTALLATION:

There are a few things which you need to take care of by hand, if you
wish to. Please note that ALL OF THESE CHANGES ARE OPTIONAL, and the
scripts will work fine if you don't feel comfortable or up to making
some minor changes by hand. The only difference is that instead of being
notified of reported viruses each time you login, you will need to run
VCHECK, the "check for virus reports" script, by hand. Do that by
typing VCHECK if you run 4DOS as your shell. If you do not use 4DOS,
type the command "4DOS /C VCHECK.BTM", and the script will run for you
and let you know if any viruses were found.

I do it this way because frankly, I don't think it's right for me to be
making changes in your LOGIN file for you. That's a dangerous thing to
do, so I didn't.

Here are the changes for auto-notification:

 Edit the Novell LOGIN file for the person who the virus notifications
 are to be sent to. Near the end of their login script, add this line:

        #4DOS /C <path>\VCHECK.BTM

 substituting the path where you told the installer your public util
 directory is. This will check to see if viruses have been reported every
 time the aforementioned "responsible user" logs in.

Another thing you may wish to change is due to a DOS "bug", IMHO. The
folks who programmed DOS decided that if someone tries to reference a
drive that does not exist, then the user should be prompted to insert a
disk into that drive and press a key. Most disastrous if you're in the
midst of a batch file, really. What happens on a single drive machine if
a user selects "B:" as the drive to scan, the system appears to have
locked down. It hasn't. DOS has just taken over the system, and is
sitting in the background waiting for you to hit ENTER.

The workaround I found for this on our network is to 1) label the drives
in the lab, so users have a visual clue that the only drive in a
single-drive machine is A:, and 2) add some checking code. How it works
is this: Each of our lab machines set an environment variable when they
boot up, with the line "SET NAME=PCx", where x is a number. Then, I
customized our script, by adding lines directly following the label
":scanner" (line 81) like this one:

        IF %NAME=PC6 .and. %DRIVE=B: set drive=A:

If you are not familiar with 4DOS, the ".and." boolean only works under
4DOS, but it's reason enough for registering 4DOS.

Be aware that the more entries you place in here, the slower
(though not much slower) your script will run, so be judicious. Assume
that lab users are the only ones out there who don't know the difference
between drive letters, and handle the people who call you saying "I told
it to scan the B drive, and it's locked my machine down!" by educating
them. They really need to know their machine's drive names.


VI. LOGIC OF OPERATION:

The scripts use color, which they need ANSI.SYS for, but if ANSI is not
there, the screens will work, but they might not be as pretty as they
are under ANSI.SYS (i.e. some system text will not be hidden as it is
with ANSI loaded). Ansi is a pretty much de-facto required DOS standard,
so I don't expect this to be a problem.

VSCAN:
It's about this distance into documentation I get reaaaaally tired of
being so precise, but I will be as specific as possible here, since this
is a description of what the scanner is actually doing step by step.

If your users are not using 4DOS as a shell, then typing VSCAN calls a
batch file, which runs the 4DOS script VSCAN.BTM under a 4DOS shell
which closes after the scan is complete.

The script checks to see if there is less than 800 bytes of environment
space available for variables. If there is, the script exits with a
message to this effect. Since there are a lot of variables in this
script, and since network paths tend to eat up a good deal of DOS's
environment space, you should likely allow for 1536 bytes of environment
space for networked machines using 4DOS as their native shell. This will
ONLY be a problem for users who use 4DOS as a shell, and have a small
environment space set in their CONFIG.SYS file. Try editing the line in
CONFIG.SYS which says:

        SHELL=C:\4DOS\4DOS.COM /P /E:XXXX

by upping the value in XXXX to 1536 or 2048, should you run into this
problem.

Secondly, the script checks to make sure it's not being run from under
Windows in 386 mode. If it is, it tells the user to exit Windows, and
then scan their system... reason being that I don't trust the Windows
32 bit disk access completely when de-virusing system areas on the hard
drive.... I've heard horror stories.

Next, the script looks into the keyboard buffer, for the character ".",
and if it finds it, the scanner exits cleanly. I did this because in our
lab, sometimes I am forced to go through ten virus scans while
configuring software in our menu system, and if I already know a machine
is clean, having to rescan just slows me down. Now, when I select a
choice from our menu which will force me to go through a virus scan, I
IMMEDIATELY hit the period key after selecting that menu item, and I can
skip the scan. Note: this is a backdoor which you should NEVER let
general users know. Keep it amongst your computer staff! You can, of
course, change this character if you wish to, or even remove it.

The scanner then does some environment variable set up. Then the scanner
checks in the user's local F-Prot directory (which you specified during
installation), and also in the network directory where you have stored
the latest version of F-Prot. It looks for the file NEW.XXX in both of
these directories, which MUST be there in the archive directory... the
XXX will be a number, which is the version number of that copy of
F-Prot. If the numbers between the directories differ, then the user is
notified that their version is outdated, and that a newer version is
being copied to their local directory, which the script then does.

The script also checks for the existence of the temp directory on the
user's hard drive, and if it does not exist, creates it.

Memory is then scanned for viruses, and also the file C:\COMMAND.COM,
which really should exist on any networked machine with a hard drive. If
you're using machines which exclusively have bootROMs, why worry about
scanning that station? It's ROM can't be infected....

If a virus is found in memory, execution is handled over to the
reporting facilities, which I will discuss later.

A check is then made to see if the user entered a command line option,
which would be a drive letter A: through D:. This means that if you
type VSCAN C:, or put something similar in a user's LOGIN file, the C:
drive will be scanned automatically. If there was a drive letter
specified, the scanner will simply scan the specified drive and then
exit to DOS, provided no uncleanable viruses are found. This was added
at the request of some virus conscious individuals on our network, but
we don't have it in the systemwide login script, because some of us who
may multitasking OS's like OS/2, and who open maybe fifty shells a day,
lose a good chunk of time to redundant rescans.

After the memory scan is completed, the user is presented with a menu to
select drives A: through C:, a HELP option, or QUIT. Choosing HELP gives
a scrolling box which displays the file VSSHELP.DAT, mentioned
previously. Choosing QUIT clears out all of the variables used by the
scanner, clears the screen, and exits.

Choosing a drive letter begins an F-Prot scan on the specified drive,
using the options /nomem (memory was scanned during startup), /auto
/disinf (clean up viruses if you can), /silent (no screen output), /old
(no messages or pauses if the F-Prot version is getting old), /command
(command line mode only), and /report=<file>, to produce a report file.
The report file is named "VREPORT.TXT" and is placed in whatever
directory you defined as the User's temp directory during the
installation process.

If a suspicious file is found (not currently a return code for the type
of scan we're doing, but put in for future expansion), the user will be
informed of this, and their VREPORT.TXT file will be concatenated onto
the log file SUMMARY.TXT, which is stored in the Report Directory on
your network, which you specified during installation.

If an infected file/disk is found which can be cleaned, it will be
cleaned automatically, and the user notified that a virus was found and
removed. Again, their VREPORT.TXT file will be concatenated onto the log
file SUMMARY.TXT, which is stored in the Report Directory on your
network, which you specified during installation.

If an uncleanable virus is found the system will be locked down, the
user's screen will turn red, a heinous alarm sound will blare out
through their speaker to let them know something is wrong, and they will
be presented with a screenfull of information regarding exactly what has
gone wrong, and that they should contact support personnel for further
instructions. The reason I decided to lock the machine down instead of
just pleasantly exiting with a "Hey, you know you've got a virus,
right?" message is that most users would tend to put that kind of
message on the backburner for a week or two, and then let you know. This
way, they want to get their system cleaned up ASAP. In any case, a copy
of their VREPORT.TXT is added onto your SUMMARY.TXT file as before, for
your perusal.

The errors possible are the same as the F-PROT errors. Read your F-Prot
documentation if you're not sure of how to handle the problem. Please
note that one possible problem is a virus scan failing because of
insufficient memory, but if your machines have 512k, this should never
be a problem. If you do have machines with 512k running on Novell in
this day and age, you're braver than I thought, and your users must have
one heck of a time using the 4k or so of conventional memory left over
after all of the network junk loads.


VCHECK.BTM:
This one is a whole lot simpler. It checks the length of the SUMMARY.TXT
file, and if the file is over 61 bytes long (the length of the header in
the file), it knows something has been added to it. If it does not find
the SUMMARY.TXT file, i.e. if you've deleted it, it creates a new one
from scratch.

If viruses HAVE been reported, you will be presented with a dialogue box
allowing you to scroll through the SUMMARY.TXT file to see the actual
F-PROT report files generated by the scans. Each one will also be marked
with a WHOAMI, to let you know who ran the scan and where they were.

The SUMMARY.TXT file will then be added to MM-DD-YY.txt, named with the
current date. Ergo, if I read the SUMMARY.TXT file on December 1st,
1995, SUMMARY.TXT would then be moved into 12-01-95.txt, and the
SUMMARY.TXT file will be reset with a current date and time line.  This
allows you to look back through your virus reports over time. Delete the
files as frequently as you wish; I do about once every three months or
so.

If you have more than one virus report notification in one day, they
will all be concatenated onto that date's file, so you won't lose any
reports you have already seen.

Please note that this is NOT a DOS batch file, it's a 4DOS script, and
there is no batch file to run the VCHECK script by just typing VCHECK.
What this means is you need to add a line to run it automatically at
each login in your LOGIN file (as described in the MORE INSTALLATION
section), or you need to be running a 4DOS shell to manually invoke the
script. I prefer to use 4DOS as my native shell... you likely will too,
once you try it out, and since it's DOS compatible, this should not
really be a problem. I refrained from writing the one line .bat file
which would allow you to run VCHECK.BTM in a 4DOS shell, so that only
those folks who know what they are doing can run the notification
script.

This is everything that goes on in the scripts. Sounds simple, I know,
but if you take a look at the scripts you will notice I do a lot of
internal safety checks. This is not a hacked out script; that was
version 1.1, which has been buried by now somewhere on my archive disks.
As a result, I hope to have taken care of a lot of the little quirks
which may arise within such a system for you. If you do run across bugs
though, please do email me, and I will do my best to correct them in a
future version. Comments are also appreciated, and even if you have
nothing really to say, let me know if you're using them, so I can at
least get some idea of if whether or not I should keep working on
release versions of this system, or whether it needs to be an internal
project again due to lack of outside interest.


VII.  NOVELL RIGHTS REQUIREMENTS

Here's a breakdown of what the rights requirements are for directories
and files under Novell, while using the Virus Scanning Scripts. These
are what your USER'S rights need to be in order to use the scripts:


Scripts Directory:         Should be in the global path, and should be
                           readable and scannable (RF).

                           The files VSCAN.BAT, VSCAN.BTM, and VSSHELP.DAT
                           should be FLAG'ed as RoS (Read-only, Shareable).

F-Prot Archive Directory:  Need not be in the global path, and should be
                           readable and scannable (RF).

                           All files under this directory should be
                           FLAG'ed as RoS (Read-only, Shareable)

Report Directory:          Need not be in the global path, and should be
                           readable, writable, creatable, modifiable,
                           and scannable (RWCMF).

                           Files under this directory will be created as
                           they are needed, so no FLAG changes are
                           needed.


VIII. LICENSE

The author of this package grants full rights for you to do anything you
wish to this package including modifications, as long as such
modifications are not distributed without both direct permission from
the author and documentation in effect to the changes made. If you wish,
feel free to fold, bend, spindle, or mutilate this, but don't spread it
as if it's the original package. I do ask that credit be given where it
is due for my work (after all, this package is free).

Use and installation is at your own risk, and the author, while
providing this package in good faith, cannot and will not be held liable
for damages or any resulting loss from use of this package.

In order to be informed of both updates, as well as bug reports, I also
request that you send email to me at [e-mail], with a note to
the efffect that you wish to be kept informed of updates. I HIGHLY
RECOMMEND THAT YOU DO THIS... I may not post about smaller updates on
the net.

Updates will usually be posted to the moderated newsgroup comp.virus,
when they become available.


IX. AFTERNOTES

This script series was originally specifically designed for our server,
so you may find that there are features you'd like to have implemented.
Please let me know if this is the case, but if you need it here and now,
you have my full permission to edit them FOR YOUR OWN USE... and at your
own risk... but please distribute only the original archive.

One common problem is that networks with multiple drive mapping schemes
(i.e. some users running LANtastic) may result in you having different
default network drive letters in some cases. If this happens, as it once
was occuring for our network here, try adding checks via something like

IF EXIST <alternate drive letter>\LOGIN\LOGIN.EXE SET ARCDIR=<alt. path>
IF EXIST <alternate drive letter>\LOGIN\LOGIN.EXE SET VSSDIR=<alt. path>
IF EXIST <alternate drive letter>\LOGIN\LOGIN.EXE SET REPDIR=<alt. path>

into the script right before the label :vercheck.

Like I keep saying: if you do some tweaking, let me know what was done
and why, so I may be able to fix it in a later version of the script. If
there are problems beyond comprehension, let me know also. I can't of
course verify this utility a thousand times over, but I am fairly
certain it should work for almost anyone.

        Good luck, and good riddance to viruses!

        Mark Hazen
        Computer Services
        College of Family and Consumer Sciences
        The University of Georgia

        Internet Mail: [e-mail]
          Bitnet Mail: mhazen@uga